Real-time network applications, such as streaming media applications, are not tolerant of transmission delays. For these real-time applications, data packets need to be delivered when they are needed by the receiving node. In the case of a streaming video or audio transmission, for example, late-arriving data will cause the end-user at the receiving node to experience choppy video or audio feed, or jittery frames on the screen. Late arriving data is discarded at the receiving node because it is useless to display an out-of-sequence data frame or segment in such real-time applications.
The predominant transport level protocol used on the Internet for high reliability data transmission is the Transmission Control Protocol (TCP). TCP was developed for traditional networks made of wired links and stationary network nodes. In wired networks, bit error rates are relatively low, so packet delays and losses are assumed to be due to congestion. Congestion is a condition of severe delay caused by an overload of data at one or more data switching points in a network (e.g., at routers). TCP includes both a data recovery mechanism that retransmits lost data, and a congestion control mechanism that reduces transmission bandwidth before retransmitting the lost packets.
TCP uses a sliding window protocol to manage the transmission and reception of data packets between a sending node (sender) and receiving node (receiver). FIG. 1A shows a sequence of data packets 1 through n awaiting transmission. The protocol places a window at the beginning of the sequence and all of the data packets in the window are transmitted in order. In the example shown in FIG. 1A, the window is 8 data packets long, so data packets 1 through 8 are transmitted sequentially. When the sender receives an acknowledgement from the receiver for data packet 1, the protocol slides the window to the right and sends the next packet, packet 9, as shown in FIG. 1B. The window continues to move to the right as subsequent acknowledgements are received, as shown in FIG. 1C.
Thus, at any point in time, data packets may be characterized as 1) data packets to the left of the window that have been sent and acknowledged, 2) data packets within the widow that have been sent and not acknowledged, or ready to send without delay, and 3) packets to the right of the window that cannot be sent until the window moves. The maximum number of sent and unacknowledged data packets is limited to the size of the window. As a result, the transmission of packets to the right of the window is delayed.
At the receiver node, data packets are processed sequentially through another sliding window that segregates data into packets that 1) have been correctly received and acknowledged, and 2) packets that have been received but not verified and/or acknowledged. If a packet is lost or delayed, the packet is recovered in one of two ways: 1) the receiver can request retransmission of the packet by sending, to the original sending node, the sequence number of the last sequential data packet received at the receiving node node, or 2) the sender can retransmit the packet if an acknowledgement is not received from the receiving node within a certain amount of time. Both of these mechanisms introduce additional delays in completing the reception of some packets (i.e., lost packets as well as packets that have not yet been sent by the source).
In addition to the data recovery process discussed above, TCP also reduces the size of the data window when data packets are lost or delayed, further reducing the bandwidth and throughput of the connection between the sending node and the receiving node.
A conventional approach used in TCP networks to improve data reliability uses caching servers in the data path to cache data close to the receiver (e.g., within a limited number of network hops). However, this approach requires dedicated, expensive caching servers at strategic locations throughout a network. Furthermore, the caching servers may increase data delay.
As noted above, TCP was developed to address the requirements of wired networks with fixed nodes. When applied to wireless networks with mobile nodes, TCP can have negative effects. Unlike wired networks, wireless networks are characterized by relatively high bit error rates and occasional signal loss, rather than network congestion. When TCP is applied to a wireless network, the reduction of transmission bandwidth by TCP in reaction to packet losses, based on a network congestion model, may result in poor bandwidth utilization, poor throughput, longer delays and poor overall performance in real-time data-streaming applications.
Conventional approaches to the problem of TCP on wireless networks include: 1) Indirect-TCP protocol which segregates the connection between a wired host and a wireless host into a wired network connection and a one-hop wireless connection which uses a wireless link specific protocol, 2) a wireless link level retransmission protocol coupled with forward error correction (FEC) at the data link level, and 3) the “Snoop Protocol” which caches packets at the wired/wireless interface and performs local retransmissions across wireless links by monitoring data packet acknowledgements by the receiver.
All of the above approaches, both wired and wireless, are based on the TCP data reliability model for network communications, rather than a delay-centric model that has greater utility for real-time multimedia applications.